The devcontainer CLI writes the `devcontainer.metadata` container label
as a bare JSON object when there is only one metadata entry (e.g.
docker-compose with a Dockerfile and no features). This causes
deserialization to fail because the current code only accepts a JSON
array.

Try parsing as an array first, then fall back to parsing as a single
object wrapped in a vec.

Upstream CLI fix: devcontainers/cli#1199
Related CLI issue: devcontainers/cli#1054

…rray (#53557)

Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

## Details

- The [devcontainer CLI writes the `devcontainer.metadata` label as a
bare JSON object](devcontainers/cli#1054) when
there is only one metadata entry (e.g. docker-compose devcontainer with
a Dockerfile and no features)
- Zed's `deserialize_metadata` only accepted a JSON array, causing
deserialization to fail with `invalid type: map, expected a sequence`
- This made it impossible to attach to existing docker-compose
devcontainers created by the devcontainer CLI or VS Code

The fix tries parsing as an array first, then falls back to parsing as a
single object wrapped in a vec. This mirrors how the [devcontainer CLI
itself reads the
label](https://github.com/devcontainers/cli/blob/main/src/spec-node/imageMetadata.ts#L476-L493).

An upstream fix has also been submitted:
devcontainers/cli#1199

## Reproduction

1. Create a docker-compose devcontainer with a Dockerfile and no
features:

`.devcontainer/devcontainer.json`:
```json
{
  "name": "repro",
  "dockerComposeFile": "docker-compose.yml",
  "service": "app",
  "remoteUser": "root"
}
```

`.devcontainer/docker-compose.yml`:
```yaml
services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    command: sleep infinity
    volumes:
      - ..:/workspace
```

`.devcontainer/Dockerfile`:
```dockerfile
FROM ubuntu:24.04
```

2. `devcontainer up --workspace-folder .`
3. Open the folder in Zed, fails with metadata deserialization error

Release Notes:

- Fixed attaching to a devcontainer that has a single metadata element
which was started with `devcontainer-cli`

…rray (zed-industries#53557)

Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

## Details

- The [devcontainer CLI writes the `devcontainer.metadata` label as a
bare JSON object](devcontainers/cli#1054) when
there is only one metadata entry (e.g. docker-compose devcontainer with
a Dockerfile and no features)
- Zed's `deserialize_metadata` only accepted a JSON array, causing
deserialization to fail with `invalid type: map, expected a sequence`
- This made it impossible to attach to existing docker-compose
devcontainers created by the devcontainer CLI or VS Code

The fix tries parsing as an array first, then falls back to parsing as a
single object wrapped in a vec. This mirrors how the [devcontainer CLI
itself reads the
label](https://github.com/devcontainers/cli/blob/main/src/spec-node/imageMetadata.ts#L476-L493).

An upstream fix has also been submitted:
devcontainers/cli#1199

## Reproduction

1. Create a docker-compose devcontainer with a Dockerfile and no
features:

`.devcontainer/devcontainer.json`:
```json
{
  "name": "repro",
  "dockerComposeFile": "docker-compose.yml",
  "service": "app",
  "remoteUser": "root"
}
```

`.devcontainer/docker-compose.yml`:
```yaml
services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    command: sleep infinity
    volumes:
      - ..:/workspace
```

`.devcontainer/Dockerfile`:
```dockerfile
FROM ubuntu:24.04
```

2. `devcontainer up --workspace-folder .`
3. Open the folder in Zed, fails with metadata deserialization error

Release Notes:

- Fixed attaching to a devcontainer that has a single metadata element
which was started with `devcontainer-cli`

Per devcontainers/cli#1199 (v0.86.0), the `devcontainer.metadata` image
label is always a JSON array of partial-config entries, even when only a
single entry is present. VS Code, Zed, and envbuilder iterate the array
and merge entries in order. Writers that emit a single object break this
contract.

Writer changes (three sites):
- crates/core/src/build/metadata.rs: DevcontainerMetadata::to_json now
  wraps in [...]. from_json returns Vec<Self> and accepts either form
  for backwards compatibility with images built by older Deacon versions.
- crates/deacon/src/commands/build/mod.rs (image-reference path, ~L1272):
  the inline {name, image} label wrapped in [...].
- crates/deacon/src/commands/build/mod.rs (docker build path, ~L1546):
  the inline {configHash} label wrapped in [...].

Reader change:
- crates/deacon/src/commands/read_configuration.rs (compute_merged_
  configuration, ~L411): parses the label as Value, normalizes to a Vec
  of entries (array as-is; object wrapped in single-element vec), then
  deserializes each entry as a partial DevContainerConfig, applies
  variable substitution, and merges with the base config in declaration
  order. Behavior for upstream-built images (array form) is now correct;
  behavior for legacy Deacon-built images (object form) is preserved.

Tests added (crates/core/src/build/metadata.rs):
- test_to_json_emits_array: asserts label starts with '['
- test_from_json_handles_legacy_object_form: legacy single-object fixture
- test_from_json_handles_array_form_with_multiple_entries: spec-form fixture
- test_metadata_roundtrip: updated for new Vec return type
- test_merge_labels_emits_array_label_value: end-to-end label assertion

Verified locally: cargo fmt --check, cargo check, cargo clippy -D warnings,
cargo nextest run --profile dev-fast --no-default-features (1930/1930 ok),
cargo test --doc --workspace (130/130 ok), 38/38 merged-configuration
adjacent tests pass.

Known follow-up (not blocking 1.0; separate ticket): the DevcontainerMetadata
struct wraps the config under a `config` subkey alongside features/
customizations/lockfile_hash. Upstream array entries are FLAT partial-config
shapes. Deacon-emitted entries today are not directly merge-able as
DevContainerConfig (latent issue pre-dating this PR). Flattening the struct
to match upstream array-entry shape would be its own refactor.

Refs: docs/ROADMAP_TO_1.0.md Tier 1 item "devcontainer.metadata label
JSON array (CLI parity B.2)".

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Per devcontainers/cli#1199 (v0.86.0), the `devcontainer.metadata` image
label is always a JSON array of partial-config entries, even when only a
single entry is present. VS Code, Zed, and envbuilder iterate the array
and merge entries in order. Writers that emit a single object break this
contract.

Writer changes (three sites):
- crates/core/src/build/metadata.rs: DevcontainerMetadata::to_json now
  wraps in [...]. from_json returns Vec<Self> and accepts either form
  for backwards compatibility with images built by older Deacon versions.
- crates/deacon/src/commands/build/mod.rs (image-reference path, ~L1272):
  the inline {name, image} label wrapped in [...].
- crates/deacon/src/commands/build/mod.rs (docker build path, ~L1546):
  the inline {configHash} label wrapped in [...].

Reader change:
- crates/deacon/src/commands/read_configuration.rs (compute_merged_
  configuration, ~L411): parses the label as Value, normalizes to a Vec
  of entries (array as-is; object wrapped in single-element vec), then
  deserializes each entry as a partial DevContainerConfig, applies
  variable substitution, and merges with the base config in declaration
  order. Behavior for upstream-built images (array form) is now correct;
  behavior for legacy Deacon-built images (object form) is preserved.

Tests added (crates/core/src/build/metadata.rs):
- test_to_json_emits_array: asserts label starts with '['
- test_from_json_handles_legacy_object_form: legacy single-object fixture
- test_from_json_handles_array_form_with_multiple_entries: spec-form fixture
- test_metadata_roundtrip: updated for new Vec return type
- test_merge_labels_emits_array_label_value: end-to-end label assertion

Verified locally: cargo fmt --check, cargo check, cargo clippy -D warnings,
cargo nextest run --profile dev-fast --no-default-features (1930/1930 ok),
cargo test --doc --workspace (130/130 ok), 38/38 merged-configuration
adjacent tests pass.

Known follow-up (not blocking 1.0; separate ticket): the DevcontainerMetadata
struct wraps the config under a `config` subkey alongside features/
customizations/lockfile_hash. Upstream array entries are FLAT partial-config
shapes. Deacon-emitted entries today are not directly merge-able as
DevContainerConfig (latent issue pre-dating this PR). Flattening the struct
to match upstream array-entry shape would be its own refactor.

Refs: docs/ROADMAP_TO_1.0.md Tier 1 item "devcontainer.metadata label
JSON array (CLI parity B.2)".

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>